1. Field of Invention
The present invention relates generally to the field of computer software. More particularly, the present invention in one embodiment is related to analyzing the usage of application programming interfaces (APIs) associated with software used in network devices such as, e.g., consumer premises devices or receivers associated with content delivery networks.
2. Description of Related Technology
Digital TV (DTV) is an emerging technology which utilizes digitized and compressed data formats (e.g., MPEG) for content transmission, as compared to earlier analog “uncompressed” approaches (e.g., NTSC). The DTV content may be distributed across any number of different types of bearer media or networks with sufficient bandwidth, including HFC, satellite, wireless, or terrestrial. DTV standards such as the OpenCable Application Platform (OCAP) middleware specification (e.g., Version 1.0, 2.0, and 3.0) require that applications be downloaded to CPE from the bearer or broadcast network in real-time. The OCAP specification is a middleware software layer specification intended to enable the developers of interactive television services and applications to design such products so that they will run successfully on any cable television system in North America, independent of set-top or television receiver hardware or operating system software choices.
Software Interfaces
The well-known application programming interface (API) is an abstract concept describing a set of functions or methods called by software, including the particular format and organization of those function calls. An API describes how applications and software developers access a set of functions (for example, within a library) without requiring access to the underlying source code of the functions or library. The computer software that provides the functionality described by the API is said to be an implementation of the API. A reference implementation of an API is the implementation created by the designer of the API against which other implementations of the API are compared.
For example, an API might describe how an application may call an image-drawing function within a graphics library, for displaying rendered graphics images on a computer display. A programmer can accordingly write a program which calls the image-drawing function described in the API. When executed, the program will use the implementation of the API (a library) to draw the image.
Application programming interfaces (API's) are often standardized in order to allow programmers to write applications and libraries that work together.
JAVA and Object-Oriented Programming
JAVA (e.g. Sun Microsystems' JAVA®) is a general purpose object-oriented programming language which can be used in a distributed environment such as for example a content-based network or the Internet. JAVA has become a common software language used to develop applications for cable set-top boxes and OCAP-compliant applications. The JAVA virtual machine (JVM) executes JAVA bytecode which is generated by compiling text files containing JAVA language syntax.
In object oriented programming languages such as JAVA, objects refer to what is run in the computer; i.e., they comprise modular units of code that make up the inner workings of a process. Each object is classified in a generic class or “type” of object. Other generic classes are defined so that objects can share models and reuse the class definitions in their code. Each object is also an “instance” of a particular class or subclass, having the class's own methods, procedures and variables. Each object contains the variables of the class of which it is an instance. The object's methods are configured to accommodate actual values that are supplied to the object when that object is being used. A JAVA object can take advantage of being part of a class of objects, and inherit code that is common to the class. It contains limited and well-controlled references to data external to the object (or other known objects).
The term “method” in the JAVA context refers to a programmed procedure that is defined as part of a class, and is included in objects of that class. A method can be thought of as one of the object's capabilities or behaviors. Classes and objects can have more than one method associated therewith. A method associated with an object can access data known to that object; this approach helps ensure data integrity among the set of objects in an application. Methods can be re-used within multiple different objects if desired.
Similarly, a JAVA “class” can be considered a template definition of the methods and variables in a particular type of object. Hence, an object is a specific instance of a class, and it contains real values instead of variables. Classes can have sub-classes that can inherit all or some of the characteristics of the class. Sub-classes can also define their own methods and variables that are not part of the class from which they inherit.
JAVA source code files are compiled into a format known as bytecode. Such bytecode files (having a “.class” extension) can be run on any device also having a JAVA virtual machine (JVM); hence, JAVA bytecode is independent of the platform on which it is run. The JVM is used to interpret the bytecode into code that will run on real computer hardware. The JVM's instruction set is stack-oriented, utilizes a variable instruction length, and supports object-oriented programming by including instructions for invocation of object methods similar to subroutine call in other instruction sets. The JVM may also include a just-in-time (JIT) compiler which directly converts the bytecode into “native executable code” (e.g., native executable hardware instructions) as an alternative to interpreting one bytecode instruction at a time.
So-called “enums” or enumerations are an optional mechanism to provide a user-defined type along with an enumeration of all of the possible values for a variable of this type. For example, the type Day might include enumerated values of Monday, Tuesday, Wednesday, and so forth. Important characteristics of such enums include (i) type safety; (ii) compact, efficient declaration of enumerated values; (iii) runtime efficiency; and (iv) integration with other language features.
OCAP-Related Requirements
As previously noted, JAVA has become the common software language used to develop applications for cable set-top boxes and OCAP-compliant applications. The Open Cable Application Platform (OCAP) middleware comprises standardized APIs put forth by the cable television industry to facilitate the creation of cable focused software applications from a variety of sources. OCAP-compliant applications can interoperate with one another and can run on OCAP complaint set-top boxes.
Programmers developing applications for cable set-top boxes must test their code to confirm that it is OCAP-compliant. Additionally, cable set top boxes operators and manufactures need effective methods for testing applications for OCAP-compliance prior to or concurrent with deployment. In many instances, the applications deployed by the MSO and received by the set-top box will be in the form of object code including compiled JAVA code.
Thus, in order to facilitate development and testing of OCAP-compliant applications, effective methods and apparatus for analyzing the application programming interface usage of a software application would be highly desirable. Additionally, it would be useful to have an application that provides feedback regarding the particular application interface used by a program to facilitate modification of a particular piece of code. This will allow developers, vendors and users of the code to evaluate and exchange information about the condition of that code more rapidly and more effectively, thereby reducing development time. And because the code will typically be exchanged in object form, it would be useful if the API of code could be determined using code that is in object form.
Prior Art API-Related Software and Solutions
A variety of different approaches to API creation, usage and management in computerized systems are evidenced in the prior art. For example, U.S. Pat. No. 6,366,876 to Looney issued Apr. 2, 2002 entitled “Method and apparatus for assessing compatibility between platforms and applications” discloses embodiments that can be used to assess whether a software application is compatible with an operating platform. A specification that describes the operating platform is generated using a definitional language. The specification identifies the programming resources of an operating platform. The application's dependencies and programming resources are identified. A compatibility engine is executed to resolve an application's dependencies to the specification. The output of the compatibility engine identifies whether the application conforms to the operating platform and how it deviates from the specification.
U.S. Pat. No. 6,460,141 to Olden issued Oct. 1, 2002 entitled “Security and access management system for web-enabled and non-web-enabled applications and content on a computer network” discloses a security and access management system that provides unified access management to address the specific problems facing the deployment of security for the Web and non-Web environment. An API server is disclosed that records all connections and disconnections of API clients in a log file. The API logon log file can be used for auditing API usage. The API server also records a summary of all transactions in a log file. The API transactions log file can also be used for auditing API usage.
U.S. Pat. No. 7,010,796 to Strom, et al. issued Mar. 7, 2006 entitled “Methods and apparatus providing remote operation of an application programming interface” discloses a system that can analyze an application programming interface definition to automatically produce software string generator and parser software components allowing remote access to functions within the application programming interface definition by processes that are not natively compatible with the computing system environment in which the application programming interface operates. A first string generator processes can produce an encapsulated function call from a first process, such as a JAVA-based process, that calls a first function in a first computing environment. A second parser process operates in a second computing environment to receive the encapsulated function call and to invoke a second function call in a second process, such as a C-based process. Results from the second function call are returned to a second string generator which produces an encapsulated response that is returned to a first parser process. The first parser process maps the encapsulated response back into first function call parameters for return to the first process, thus providing access to second functions of the application programming interface by the first process.
U.S. Pat. No. 7,080,356 to Atallah, et al. issued Jul. 18, 2006 entitled “Certification test suite” discloses a system and method for assessing binary compatibility between software modules permits software developers to register with a system, download software tools for testing binary compatibility between their software products and one or more ABIs. The system further enables software developers to certify their binary compatibility with one or more ABIs by uploading compatibility information to the system. A unique identifier of the software, e.g., the MD5 signature of the binary code, may be uploaded with the results of the compatibility test. The results of the compatibility test and the unique identifier may be stored in a database to record whether the developer's software is binary compatible with one or more of the ABIs. In addition, computer users may register with the system, utilize a tool that collects the MD5 signatures of the binary files on their computer(s) and forward the MD5 signatures to the system. The system may receive the MD5 signatures, compare them to the MD5 signatures on record, and generate a report indicating the binary compatibility of the files resident on the user's computer system.
United States Patent Application Publication No. 20020198868 to Kinzhalin, et al. published Dec. 26, 2002 and entitled “System and method for specification tracking in a JAVA compatibility testing environment” discloses collecting information on a specification of a computer program. A plurality of classes is provided, where each class is capable of performing a particular task related to obtaining information from a specification. Then a command is received from a user. The command requests a particular task to be performed. A class is then selected from the plurality of classes based on the task requested by the received command, and the selected class is run. In this manner, information on the specification is obtained. The plurality of classes can include a get assertion class that obtains assertions from the specification, and a reporting class that provides information on test coverage of the specification.
A number of API-related software packages are also commercially available at present. These generally comprise programmatic analysis software in support of generating documentation, and are typically rendered in the form of a command-line user interface (UI). Two examples of such API documentation software are JavaDoc and Doxygen. Both the tools perform code analysis focused primarily on the automated documentation of APIs. However, both tools rely heavily on the source code (e.g., in-line source code comments), and mechanisms to properly generate documentation.
One example of a prior art API verification tool useful specifically within the OCAP environment is the XAV tool, which is an application evaluator that ensures interoperability with the OCAP standard. XAV applies objective repeatable tests to the set of resource files that compose an application. XAV generates and application summary report showing the total of tested resources, failures, and untested resources.
However, while XAV is effective for simple OCAP verification, it notably does not support API usage analysis or coverage. In the present context, the term “coverage” refers without limitation to whether or not an application simply makes a call on an interface (e.g., API), whereas the term “usage” refers without limitation to evaluation or determination of whether an application is using the interface correctly or not. Such information would be highly useful to provide real-world feedback to developers regarding issues such as the number of functions calls, as well as classes and methods that must be supported.
Thus there is a need for a software tool and associated methods useful for analyzing code for aspects including inter alia API usage and coverage, and providing detailed reporting back to the developer or operator. Such software tool and methods would also be adaptable in particular to the OCAP software environment, thereby affording content delivery network operators, application developers, and DSTB or other CPE manufacturers and vendors an effective and convenient means for validating and analyzing prospective software applications for use in such content delivery networks.